%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 7
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 7: Employee Web App (M3)}

In the seventh iteration we decompose the \emph{Employee Web App} component. For this decomposition we consider QaS M3: "Debt and credit cards". The use cases that are relevant to this are:
\begin{itemize}
 \item UC21: Pay interests
 \item UC22: Update interest rate
 \item UC18: Block bank card
 \item UC3: Register new customer
\end{itemize}

In this iteration we will thus provide the functionalities for the SAB CFO so he or she can update the interest rate, we will provide the functionality for paying interests on savings accounts, and we will prepare the system for future modifications that will add debt and credit cards to SAB's services. We will also provide the functionalities for the bank clerk to block bank cards and register a new customer.

These drivers can be summarized in the following requirements:
\begin{itemize}
 \item Credit cards of external companies (e.g. Visa, MasterCard) will be supported in the future.
 \item Debt on checking accounts will be supported in the future.
 \item Interests have to be processed and paid when they are are triggered. To support this, the interest rate, and the lowest balance for each day has to be stored.
 \item In the future, interests on checking account debts will have to be processed similarly to interests on savings accounts.
 \item The SAB CFO has to be able to update interest rates, these interest rates need to be stored.
 \item In the future, interests on checking account debts will have to be updated similarly to interests on savings accounts.
 \item The Bank Clerk should be able to block bank cards.
 \item The Bank Clerk should be able to register a new customer.
\end{itemize}


To satisfy these drivers we considered different modifiability tactics to find an appropriate solution:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tactics
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{description}


    % Tactic problem
    \item[Localize Modifications:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Maintain semantic coherence:] Different functionalities are encapsulated and abstracted in separate components that can run in their own environment. Existing components are reused where possible. This way reuse and modifiability are supported.
            \item[Anticipate expected changes:] The decomposition is made with the future support of debt and credit cards in mind.
            
            \item[Limit possible options:] Decompositions are shown in component diagrams which illustrate the border and interfaces of encapsulated processes. 
        \end{description}
        
 
 
     % Tactic problem
    \item[Prevent ripple effects:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Hide information:] Information hiding by isolating specific interfaces helps to prevent ripple effects by enabling modular design.
            
            \item[Maintain existing interfaces:] Abstract interfaces can be provided to mask variations.
            
            \item[Use an intermediary:] An intermediary can be used to encapsulate and group specific functionalities. This way ripple effects can be prevented.
        \end{description}
        
        
        
        
    % Tactic problem
    \item[Defer binding time:] \hfill \\
    
        \vspace{-5mm} 
        \begin{description}
            % solutions for problem
            \item[Runtime registration:] The distributed design requires interacting components to register with each other, requiring publisher/subscriber-like patterns. The components can run on separate computers and can communicate even over a wide area network.
            
            \item[Component replacement:] New components can be added easily through runtime registration.
        \end{description}
        
\end{description}      

        
% Insert figure
\begin{figure}[!ht]
    \centering
       \includegraphics[width=1.0\textwidth]{images/It7_M3_componentdiag.png}
    \caption{Component diagram after iteration 7.}
    \label{fig:It7_M3_componentdiag}
\end{figure}


In this iteration we will decompose the \emph{Employee Web App} into \emph{Employee Web App Front End}, \emph{Bank Clerk Module} and \emph{CFO Module}. An extra \emph{Interest Module} to manage interests and support UC21 and UC22, and a \emph{Bank Card Module} to manage bank cards and support UC18 will also be provided [figure \ref{fig:It7_M3_componentdiag}].

SAB Employees will login via de \emph{Employee Web App Frontend} which uses the already provided \emph{Login Module}. The \emph{Login Module} maintains a separate list of employee accounts. This \emph{Employee Web App Frontend} will then provide the necessary functionalities of the \emph{Bank Clerk Module} or \emph{CFO Module}, depending on who is logged in, in the form of an interactive website.

The \emph{CFO Module} encapsulates the functionalities for the SAB CFO. It is connected to the \emph{Interest Module} to allow the SAB CFO to update the interest rates. The \emph{Interest Module} will hold a history of set interests so that a correct interest payment can be calculated. The \emph{Interest Module} is connected to the \emph{Customer Information} component so that it can access the balance history of each savings account to calculate the corrects interests. It is connected to the \emph{Transaction Processing System} so that calculated interests can be issued through a transaction command.

To support all this, a transaction command that pays the interest needs to be implemented for the \emph{Transaction Processing System}. This \emph{Transaction Processing System} already has all the functionalities to correctly execute the necessary actions (i.e. updating account balance, sending notifications and logging the transaction to the history) needed for processing interest payments. The responsibility to keep a history of the lowest balances of each day is also added to the \emph{Balance Database}. Expected changes are anticipated and in the future, processing the interest of debt can be added to this \emph{Interest Module}.

The \emph{Bank Clerk Module} encapsulates the functionalities provided for the bank clerk. It is connected to the \emph{Transaction Processing System} and \emph{Customer Information} components to provide the functionalities tackled in previous iterations (i.e. Selecting Customer, Handling Cash). The \emph{Bank Clerk Module} is also connected to the new \emph{Bank Card Module}. This component will provide the functionality to verify bank card numbers and to block or request cards when needed. The \emph{Bank Card Module} will then notify the appropriate bank card company. In the current implementation this component will only block debit cards and notify this to Atos Worldline, but expected changes are anticipated and in the future it will also provide this functionality for other bank card companies.

The \emph{Bank Clerk Module} will also provide the functionality to register new customers to support UC3. To do this it will need to be able to deliver information via the \emph{Customer Information} facade to the \emph{Account Database}. The \emph{Bank Clerk Module} itself will be responsible for validating the entered information and signals a warning to the \emph{Employee Web App Front End}. The bank cards that need to be sent to the new customer are requested via the \emph{Bank Card Module} which will then notify the appropriate bank card company.

To further support the future incorporation of credit cards a specific transaction command can be implemented for the \emph{Transaction Processing System} to handle notifications about credit card payments and withdrawals sent by the credit card company. The system already supports all the functionalities to correctly execute the necessary actions. Credit card companies will be able to use direct debits to reclaim their debts. The functionality of direct debits will be added in a future and iteration to keep this iteration from losing its overview on the \emph{Employee Web App}.



Requirements can be divided over relevant components as follows:
\begin{itemize}

	\item \emph{Employee Web App Front End}
	\begin{itemize}
		\item UC18: Block bank card
		\item UC7: Deposit cash
		\item UC8: Withdraw cash
		\item UC9: Issue transfer between two accounts
		\item UC22: Update interest rate
		\item UC3: Register new customer
	\end{itemize}
	
	
	\item \emph{CFO Module}
	\begin{itemize}
		\item UC22: Update interest rate
	\end{itemize}
	
	
	\item \emph{Bank Clerk Module}
	\begin{itemize}
		\item UC18: Block bank card
		\item UC7: Deposit cash
		\item UC8: Withdraw cash
		\item UC9: Issue transfer between two accounts
		\item UC3: Register new customer
	\end{itemize}
	
	
	\item \emph{Interest Module}
	\begin{itemize}
		 \item UC21: Pay interests
 		 \item UC22: Update interest rate
		 \item M3: In the future, interests on debts will have to handled similarly to interests on savings accounts.
	\end{itemize}
	
	
	\item \emph{Bank Card Module}
	\begin{itemize}
		\item UC18: Block bank card
		\item M3: Credit cards will be supported in the future
	\end{itemize}
	
	
	\item \emph{Customer Information}
	\begin{itemize}
		\item UC3: Register new customer
	\end{itemize}
	
	





\end{itemize}

